An instant messenger (IM) application enables real time communication among online participants. By way of background, an IM application typically includes functionality for allowing an IM user to define a group of participants with whom the user frequently communicates. After defining such a group, the IM application typically notifies the IM user when any member of the group happens to be online. The IM user then has the option of starting a communication session with one or more members of the group. Or the IM user might be contacted by another member who happens to be online. These events prompt the IM application to open a user interface (UI) pane that presents an evolving sequence of textual messages transmitted among IM conversation participants.
FIG. 1 shows an overview of a representative IM system 100. The system 100 includes a collection of client devices (102, 104, . . . 106) connected together via a coupling mechanism 108 (e.g., the Internet). A user Alice (A) operates client device A 102, a user Bob (B) operates client device B 104, and a user Carol (C) operates client device C 106. FIG. 1 shows that client device A 102 provides a conventional user interface pane 110. The user interface pane 110 identifies Alice's friends in a contact list 112, and also identifies whether these buddies happen to be currently online. Assume that Bob and Carol are two members of Alice's contact list 112 who happen to be currently online.
In recent years, providers of IM applications have attempted to provide a more engaging user experience by adding supplemental features to the above-described basic IM functionality. For instance, Microsoft Corporation of Redmond, Wash. has developed an MSN Messenger application that includes various features that exhibit dynamic behavior (such as Messenger's “Winks” feature, etc.). These features may provide an animated vignette for presentation in an IM pane, or other kind of non-static presentation. To achieve this dynamic behavior, such content may contain executable instructions that command the client device to perform operations during runtime. Such content can be implemented in various ways, such as by Flash functionality developed by Macromedia, Inc. of San Francisco, Calif. Flash movies contain vector-based animation graphics, and may contain script-type instructions (ActionScript) embedded therein. (More specifically, Flash Player is the ActiveX control provided by Macromedia that that can be used to provide playback of Flash movies (e.g., .swf files) in an IM application.)
However, the incorporation of executable content into an IM application also introduces significant challenges. Namely, there is a risk that a user (or some other entity) may intentionally or unintentionally introduce malicious content into an IM system. For example, instead of merely controlling the presentation of an IM feature, the dynamic component of malicious content may improperly access files, install unwanted code, destroy system resources, activate undesired user interface presentations, activate webcam functionality, and so forth. Such malicious content may therefore cause great disruption and damage within an IM system, detracting from the otherwise engaging and desirable nature of dynamic content.
Indeed, while the threat of computer viruses poses a pernicious problem in any computer environment, the consequences of such viruses in an IM system may be particularly severe. This is principally due to the automatic manner in which IM applications propagate information among participants. For example, the propagation of a virus via an Email application often depends on a user taking the express step of activating executable content that accompanies the Email as an attachment. In IM applications, however, it is often desirable to automatically execute such content without the user's approval. A network of interrelated IM groups might therefore constitute a very susceptible conduit for the rapid spread of malicious content.
Consider, for example, the case in which Alice uses her client device A 102 to retrieve content 114 that happens to have a virus. For example, assume that Alice visits a website that provides a library of animated icons supplied by a content provider. Assume that Alice selects one of these animated icons and downloads it to her local client device A 102 for use in communicating with her buddies. For instance, Alice can adopt the downloaded animated icon as an integral part of the set of information that she provides to her buddies when communicating with them, e.g., such that, for instance, Bob will see Alice's animated icon when conducting an IM session with Alice. However, transfer of the animated icon will also transfer the virus along with it. Bob himself may then further automatically propagate the virus to all of the members on his contact list, and so on, possibly without these users being aware that they are conduits in the spread of the virus. The reader can readily appreciate that an IM application can therefore rapidly spread a virus through a very large pool of IM users. To provide a more specific idea of the magnitude of this problem, there are roughly 200 million MSN IM users today; it is conceivable that an executable content-borne virus could spread through such a group in a matter of hours.
The industry has provided numerous tools to reduce the risk of computer viruses. But these tools do not provide suitable safeguards in an IM application due to the above-identified characteristics of this kind of environment. That is, traditional anti-virus tools typically aim at generality, attempting to provide the most effective techniques for stopping the spread of viruses, regardless of the source of the content or the end-use application of the content. Traditional approaches typically go about this task by developing a very inclusive database of known malicious content. These approaches then compare a particular content item under review with this database, to determine whether the content item contains any viral content that matches information in this database. McAfee, Inc. of Santa Clara, Calif. is one well-known provider of virus protection services that maintains a large database of known malicious content. However, this body of malicious content constantly changes in response to the development and introduction of new forms of viruses. Thus, a consumer may encounter a virus before a traditional virus protection system has properly identified the virus and added it to its database of known malicious content. Since the consumer lacks safeguards against this new virus, the consumer may consume the virus, opening the consumer's computer resources up to whatever damage that the virus may inflict. Traditional systems cope with this problem by acting as quickly as possible to stem the further spread of such a virus. This approach—which implicitly accepts a limited amount of damage—may work sufficiently well in the context of traditional communication routes (such as Email). But, as explained above, an IM application is unique in its potential ability to very quickly propagate malicious content among users (without even requiring the active participation of the users). Hence, the “acceptable limited damage” paradigm might not provide satisfactory results for an IM environment, because, in fact, the damage may be neither acceptable nor limited.
A number of other solutions have been developed to mitigate the spread of viral content, but again, these solutions are not well suited for an IM application. Consider, for example, the system 200 of FIG. 2, which shows one well-known approach to protecting computers against attacks from malicious content. In this well-known scheme, a content publisher 202 constitutes any entity that is set up to download content 204 to a client device 206. In this example, the content publisher 202 can comprise a company (the fictitious “XYZ Corp.”) that produces code for dissemination to a client device 206. For instance, the content publisher 202 may maintain a website that allows the user to download code upon the request of the user who wishes to purchase such code.
The content publisher 202 will wish to assure the user of the client device 206 that the code that the user is downloading is safe (e.g., that the code contains no viruses). It performs this task with the assistance of a certificate authority (CA) 208. VeriSign, Inc. of Mountain View, Calif. serves as one commonly used certificate authority. By way of overview, the purpose of a certificate authority 208 is to vouch for the identity of a publisher of content, much like a passport, issued by a government, vouches for the identity of a traveler. Namely, the content publisher 202 will typically furnish information to the certificate authority 208 that verifies its identity, and, in response, the certificate authority 208 issues a certificate that the content publisher 202 can offer to its customers as proof of its identity. In other words, the recipients are asked to trust the content due to the fact that it is “vouched for” by the certificate authority 208. FIG. 2 indicates that the XYZ Corp. content publisher 202 interacts with a fictitious Trusty Co. Inc. certificate authority 208. The online community has not mandated the use of a single (exclusive) certificate authority, so an online environment will typically provide several well-known authorities that can be used (e.g., as denoted in FIG. 2 by certificate authority 210, certificate authority 212, and so forth).
In a typical security procedure, the content publisher 202 will sign the content 204 with its private key. A signing operation comprises encrypting the content (or a digest of the content) with a private key. The signing entity then sends the signed content along with the certificate to a client device. The public key (which is the counterpart of the private key used to sign the content) is used by the client device to decrypt the encrypted content.
Upon receipt of the decrypted content, the client device 206 can examine the certificate to determine whether it originates from a trusted source. More specifically, a certificate may be linked to other certificates in a hierarchical chain of trusted relationships, reflecting a corresponding chain of entities that have vouched for the integrity of the content provider which disseminates the content. (Parts of the chain may be pre-installed on a client device as part of its core operating system functionality.) The client device 206 determines whether the received content can be trusted by “following” this chain up the hierarchy to determine whether it terminates in a certification authority that is trusted, such as, in this case, Trusty Co. Inc.
One well-known technology for facilitating the above-described process is Authenticode™ provided by Microsoft Corporation. Among other functions, Authenticode presents information, which, in conjunction with other enabling applications (such as Microsoft Corporation's Internet Explorer), can be used to provide a user interface (UI) presentation 214 that alerts the user to the fact that they are attempting to install a particular content item having certain characteristics. The UI presentation 214 may specifically identify the name of the program (i.e., the fictitious ABC program), the name of the content publisher 202 (i.e., XYZ Corporation), and the name of the certification authority 208 (i.e., Trusty Co. Inc.) that is ultimately vouching for the integrity of the content that has been received. The UI presentation 214 typically includes command buttons that prompt the user to decide whether they wish to install the content (“YES”), whether they wish to forego the installment (“NO”), or whether they require more information to make a decision (“More Info”).
The above-described security paradigm is not ideal for the IM environment described in connection with FIG. 1. First, assume that an Authenticode-type UI presentation was presented to Bob to alert Bob to the animated icon that his friend, Alice, wants to invoke on his machine. Even if Bob was made aware of the content publisher who created the animated icon, it is quite possible that Bob would not have any insight into the trustworthiness of that entity. The UI presentation may also identify the certification authority which vouches for this company, but Bob may not have heard of that company either, or, if Bob knows of that company, this may be insufficient to allay his concerns regarding the trustworthiness of an otherwise unknown content publisher. In typical practice, a user may simply press “YES” in response to prompts of an Authenticode-type UI presentation because of a false sense of security associated with the fact that a trusted friend is sending him the content. This, of course, can lead to disastrous results for the receiving user and the IM system as a whole. Second, the type of intrusive UI presentation 214 shown in FIG. 2 may be distracting or cumbersome, and may be particularly inappropriate in an IM environment which attempts to create a casual, simple, and enjoyable user experience.
Finally, existing security provisions do not allow content providers and certificate authorities to effectively apply their services to achieve beneficial marketing objectives.
For at least the above-identified reasons, there is an exemplary need for more satisfactory strategies for validating content transferred over a communication channel, such as, but not limited to, a network that implements an IM application.